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Sir: 

Applicant respectfully requests a Pre-Appeal Brief Request for Review, based upon the 
failure of the Final Office Action to establish a prima facie case of obviousness under 35 U.S.C. 
§ 103. As outlined below, the applied references fail to disclose one or more claimed elements 
recited in Applicant's independent claims. For at least this reason, the obviousness rejections 
under 35 U.S.C, § 1 03 are improper and must be reversed. By setting forth the clear grounds of 
error, Applicant does not assert that these are the only errors that the Final Office Action has 
made, nor does Applicant waive any arguments thai may be asserted in an Appeal Brief. 

The Office Action rejected claims 7-10, 12-13 and 22-23 under 35 U.S.C. § 103(a) as 
being unpatentable over Adaytum Software ("Adaytum") in view of Elkin et al. (U.S. Patent 
Publication No. 2007/0179828, hereinafter "Elkin"), in view of J. J. Halliday et al., "Flexible 
Workflow Management in the OPENflow System," (hereinafter, "Halliday") and further in view 
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of Petra Heinl et ah, "A Comprehensive Approach to Flexibility in Workflow Management 
Systems," (hereinafter, "Heinl"). The Office Action rejected claims 24-31 under 35 U.S.C. 
§ 103(a) as being unpatentable over Adaytum, Elkin, Halliday, and Heinl in view Du, et al. (U.S. 
Patent 6,308, 1 63). Applicant respectfully traverses the rejections. The applied references fail to 
disclose or suggest the features defined by Applicant's claims, and provide no apparent reason 
for modification to arrive at the claimed features. 

Applicant's claim 7, for example, requires modifying, by a computing device, a checked- 
out individual one of nodes of an enterprise planning model without preventing execution of an 
enterprise planning session for the nodes of the enterprise planning model that are not checked- 
out, wherein at least one of the nodes of the enterprise planning model that are not checked-out 
receives contribution data from the checked-out individual one of the nodes without taking the 
model offline . See, e.g., Applicant's specification, [051], [074]. Elkin in view of Adaytum 
Software, Heinl, and Halliday fails to disclose or suggest the requirements of claim 7. 

The Final Office Action asserted that "the node level operation for online node to receive 
data from a checked-out node is readily disclosed by Heinl." Final Office Action dated July 28, 
2010, p. 4 HI. In support of this assertion, the Office Action cited Heinl, p. 85 col. 2 Ijl and p. 86 
col. 2 If 5, "where allowing 'dirty reads' one or more of online nodes will be able to read and 
receive partial data from a checked-out node." Applicant respectfully submits, however, that 
Heinl fails to disclose or suggest wherein at least one of the nodes of the enterprise planning 
model is are not checked out receives contribution data from the checked-out individual one of 
the nodes without taking the model offline, as required by claim 7. 

Heinl generally discloses checking out a workflow type such that only one person can 
edit the workflow type, and thus that this workflow type is locked with respect to a second 
person. Heinl, § 4.2.2. Applicant respectfully submits that a workflow type, as described by 
Heinl, is does not disclose or suggest a node of an enterprise planning model. An enterprise 
planning model, as required by claim 7, "defines hierarchically arranged nodes associated with 
business logic software modules and enterprise contributors." Workflow types of Heinl, on the 
other hand, "model business processes .... A workflow type may be instantiated in order to 
represent a performing occurrence of a busmess_process ." Heinl, § 1 (emphasis added). 
Accordingly, to the extent that Heinl may disclose modifying a checked out workflow type, such 
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disclosure is not relevant to the requirements of Applicant's claim 7, which requires modifying a 
checked-out individual one of nodes of an enterprise planning_model . 

The Final Office action further confuses the distinction between a workflow model and 
an enterprise_planning model by incorrectly reading the language of claim 7 to require a 
"workflow model." Final Office Action dated July 28, 2010, p. 1 0. Claim 7 requires an 
"enterprise planning model" not a "workflow model" and therefore the disclosure of Heinl is not 
relevant to Applicant's claim 7. 

To the extent that Adaytum may disclose nodes of an enterprise planning model, the 
applied references do not disclose or suggest how to apply the techniques of checking out a 
workflow type, as disclosed by Heinl, to a node of an enterprise planning model. Because a 
workflow type specifies a suitable execution path to travel from a start point to an end point, 1 a 
workflow type of Heinl is not associated with a set of data and cannot receive contribution data, 
contrary to the requirements of claim 7. Thus, the techniques described by Heinl with respect to 
checking out a workflow type cannot be readily combined with the disclosure of Adaytum to 
arrive at the requirements of claim 7. 

Even i f Heinl did disclose modifying a checked-out node of a model, to which Applicant 
does not acquiesce, Heinl still fails to disclose or suggest that at least one node of an enterprise 
planning model that is not checked-out receives contribution data from the checked-out 
individual one of the nodes without taking the model offline, as required by claim 7. Tn Heinl, 
there is no interdependency between workflow types. That is, one workflow type cannot receive 
data from a workflow type that is checked out while the checked-out workflow type is checked 
out, At most, a modeler is able to receive a specification for a workflow type to edit a separate 
workflow type specification. Heinl, § 4.2.2,p. 85, col. 2, 1 1. Editing a separate workflow type 
specification based on a checked-out workflow type specification does not disclose or suggest at 
least one node of an enterprise planning model that is not checked out that receives contribution 
data from a checked out individual one of the nodes of the model, without taking the model 
offline, as required by claim 7. 

To be clear, workflow types of Heinl specify execution paths to travel from one point to 
another. Workflow types of Heinl, as noted above, do not store contribution data. In other 



1 Heinl, p, 81, col. 1, § 2.1 (stating that "suitable execution paths" for coming "from the start to the end point" are 
"directly specified in the workflow type"). 
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words, to the extent that Heinl may disclose referencing a work type specification by concurrent 
modelers (e.g. , Heinl, p. 85, col. 2), Heinl does not disclose or suggest receiving, with a non- 
checked -out node, contribution data from a checked out node of an enterprise planning model 
while the checked-out node is checked out. An enterprise planning model defines hierarchically 
arranged nodes, as required by claim 7, In addition, nodes of the enterprise planning model are 
associated with contribution data. Thus, in the context of claim 7, there are two types of data: 1) 
the definition of the model, and 2) contribution data associated with a node of the model. 

The Final Office Action fails give proper weight to the distinction between the definition 
of the model and the contribution data. Claim 7 distinctly claims and separately requires a node 
and contribution data. The Final Office Action's argument relies on construing a workflow type 
as both a node and as contribution data. For example, the Final Office Action improperly argues 
that '"contribution data' is merely a non-functional descriptive label" and "as long as one node 
of [the] enterprise model that is not checked out [is] able to receive any data from a checked out 
node without taking model offline it meets the claim." Final Office Action dated July 28, 2010, 
p. 4. The Final Office Action attempts to effectively read away the district meaning of 
"contribution data" in contrast to a "node" by construing contribution data as "any. data." The 
Final Office Action then proceeds to equate a first workflow type receiving a second workflow 
type to a node receiving contribution data. While a first and a second workflow type arc each a 
workflow type, a node and contribution data cannot be similarly equated. Consequently, 
workflow types of Heinl do not have associated contribution data, contrary to the requirements 
of claim 7, and thus Heinl (even in view of the other applied references) fails to disclose or 
suggest a node of an enterprise planning model that is not checked out that receives contribution 
data from a checked-out individual one of the nodes as required by claim 7. 

Halliday also fails to disclose or suggest the requirements of claim 7, e.g., that a node of 
an enterprise planning model that is not checked out that receives contribution data from a 
checked-out individual one of the nodes without taking the model offline. Similar to Heinl, 
Halliday is also directed to a workflow model. Halliday, Abstract. The Final Office Action cited 
page 7 of Halliday, asserting that tasks are individual nodes of workflow. Final Office Action 
dated July 28, 2010, p. 1 1. However, tasks of a workflow model, as discussed above with respect 
to Heinl, are not the same as nodes of an enterprise planning model. For example, tasks are not 
associated with contribution data, as required by Applicant's claim 7. Thus, to the extent that 
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HalHday may disclose changing tasks of a workflow model, such disclosure would not disclose 
or suggest the requirements of Applicant's claim 7, even in view of the other applied references. 

In addition, Halliday states that changes to a workflow model "must be performed 
consistently ... to a workflow schema instance [and] are carried out atomically (either all 
changes are performed or none) with respect to the normal processing activities." Halliday, p. 7, 
§ 2.3. A system according to Halliday cannot provide a node of an enterprise planning model 
that is not checked out that receives contribution data from a checked-out individual one of the 
nodes without taking the model offline, because all updates in the system according to Hailliday 
are made at the same time. 

For at least these reasons, independent claim 7 is patentable over the applied references. 
Independent claims 24 and 28 include similar requirements, for which similar remarks apply. 
Therefore, claims 24 and 28 are also patentable over the applied references. The dependent 
claims, i.e., claims 8-10, 12, 13, 22-23, 25-27 and 29-31, incorporate the subject matter of the 
respective independent claims. 2 Accordingly, for at least the reasons discussed above, all of the 
pending claims are patentable over the applied references under 35 U.S.C. § 103(a). Applicant 
respectfully requests withdrawal of this rejection. Please charge any additional fees or credit any 
overpayment to deposit account number 50-1778. 



Date: October 27, 2010 




SHUMAKER & SIEFFERT, P.A. 
1625 Radio Drive, Suite 300 
Woodbury, Minnesota 55125 
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Facsimile: 651.735,1102 



2 35 U.S.C. § 112,f 4. 
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